DezaDiskTool: a piece of trash with marginal use.
  A 64bit windows executable for ripping files from Dezaemon 3D Save Disks and building new disks.
  Frankly, it's a quickly made stopgap for lack of existing tools.  Somebody make something more useful than this, please ;*)

  Input & output use .ndd format disk dumps or .ram save-only portions of those dumps.  D64 is not supported.  You can also import specially-structured directories or zip archives.
  Opening a disk will automatically set the disk region, type, and entrypoint.  All current files will be removed.  Use "Merge Disk" from the Tools menu if you want to append to the current list.
  Opening RAM will display an option to change disk type if different.  Only RAM files will be replaced; the stub and ROM region are unaffected.
  
  Data is divided into the boot stub (EXE), ROM area, and RAM area.  Each is assigned a tab.
  Each tab contains a list of file entries.  Files with an "R" attribute are read-only, only listed in the Game Select menu.  Files with "H" set are hidden.  In the Japanese version they won't appear at all, but in the English translation they are only excluded from the File Select menu.  "*" are entries that must exist, they can only be replaced.
  *) Use a mouse wheel to scroll the file entries up and down.
  *) Double-click a file entry to open a submenu to manage its data.
  *) Right-clicking in the file list area opens a submenu for tab operations.
  
  To add a file, press the Insert key or right-click in the list and select "Import File".  Load the file and rename it if required.  If it matches an existing entry in this tab its data will be replaced.  Otherwise, a new entry is created.
  Delete a file by either selecting it and pressing the Delete key or double-clicking it and selecting "Delete".  A file with the "*" attribute can't be deleted.
  Rename a file by either selecting it and pressing F2 or double-clicking it and selecting "Rename".  A file with the "*" attribute can't be renamed.
  
  There are four save options:
  *) Save as New Disk: creates a new 64DD disk containing the current files.  Please note this is NOT a file manager!  Your old disk's system area, etc. are not used in this process.
  *) Save as New RAM: exports just the RAM portion of the disk.  This allows you to change only saved data, usable with certain emulators and hardware.  It can also be written back to an original 64DD disk.
  *) Export to Directory: creates three subdirectories in the provided directory--EXE, ROM, and RAM--and saves the current files to each.  By default, known compressed file types are decompressed.  This can be changed in the Options menu.
  *) Export to Archive: instead of creating a directory tree, this saves the files in a zip archive.
  
  Exporting is always allowed.  Saving a disk or RAM is only enabled when no errors appear in the file lists (red entries).  The most common causes are due to data overruns (won't fit on this disk type) or invalid filenames.  This program isn't smart enough to rebuild deleted data entries.  Select "Clean All Dead Entries" from the Tools menu to automatically remove deleted files.
  Individual files can also be exported by double-clicking them and selecting "Export", and tabs have their own options for batch export in the right-click menu.
  If a certain file always throws a decompression error (especially development GAM files), you can use the "Force Full Decompression" option to unsafely try to force extraction.  (It won't compress on import though unless you force that too.)

  By default, exported data is decompressed and imported data--when the type can be identified--is compressed.  These settings can be changed in the Options menu.  Recompression can take a long time, so there are advantages to extracting compressed files if you're going to be importing large batches of them later.
  Disk region and type can be changed in the Options menu.  When changing types, only those that can contain the current amount of files are enabled.  To make more available, delete files from the lists.

  The "Entrypoint" field changes the address the 64DD boots to if you run as a disk without a cartridge.  The program MAIN.BIN will be loaded to this address.  After changing the address, either press Enter or click elsewhere to update the value.  If it's a valid address (and the entire binary fits in memory without overwriting the IPL) the new value is used.  Otherwise, the old value is restored.


  This program is not smart.
  1) ...or user friendly.
     It takes forever to load.  There are no progress bars, no undo or cancellation, few completion messages, and the program will be unresponsive while doing...pretty much anything.  Patience is a virtue?
     There's no file sorting into game collections or tests that all required files are present.  Provided is only a baseline "tool of desperation" until something shinier comes along.
  2) It's a fluke if exported files match imported files.  This is *not* a file manager but a chinsy tool that builds new files or rips apart old ones.  It does not accept LBA usage maps.  Dead entries, uncleared data, etc. are not retained.
  3) "DEZA3D.HSC" and "DEZA3D.SYS" should never be placed in the ROM area!  These keep your scores and settings.  They must be mutable!
  4) File order only matters to humans.  Append & replace are the only supported modes.
  5) There's no enforcement for unique entries.  Most file lookup (but not all) checks for the first instance of a filename in ROM, then RAM, then cart.  Double-entries are "lost" (or overloaded), but the program is too dumb to check for that and who knows?  Maybe there's an edge case where that's useful.
     Batch exporting files will overwrite any with the same name, like the millions of deleted copies of your settings it loves to make.
  6) Filenames must be all-caps, 8.3, with limitations on extensions.  8.3 is mandated by the filetable format.  CAPS are only mandatory for displayed filenames but forced out of this programmer's convenience.
     Filenames can only contain these displayable characters (not necessarily displayed as such): " !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_"
     Internally these files have expected sizes and it's hardcoded what is and isn't compressed.  There's no data verification.  Changing names or extensions could seriously screw things up.
  7) Removed files (red entries, starting with a "`") can usually be extracted from imported disks.
     Removed files MUST be purged before saving as disk or ram.
  8) Disk type is NOT automatically changed based on the size of the ROM area.  It's a good idea...for someone else to implement.
     Disk type detection may not work correctly depending on how your data is structured.
     [You can ignore this rant if you like.]
     Actual hardware checks what parts of the disk throw an error because they weren't written to.  NDD requires an external LOG file to know this (not unlike bin/cue); the table in the stub isn't reliable.  Detection without one is based on data and yes, you can (mostly) craft an impossible dev+retail disk from an emulator's point of view.  For end-users (non-archival purposes) D64 is overkill, in fact most of the system info can be manufactured on-demand (which is how you convert to D64, much of the necessary data isn't dumpable yet).  All that's really needed is a cue with the disk type, boot info, label, and pointing at many bins of the actual stored data.  Unlisted is assumed unwritten.
  9) Stubs are a necessary problem.
     The main executable must be named "MAIN.BIN" and must contain *something*.  It cannot be deleted or renamed but can be replaced.  Encryption is NOT implemented.  Remember this is what the 64DD will boot to if you don't provide a cartridge.  Placing something nonexecutable would be bad.
     There is no size check on main.bin but yes, there should be because...
     If you replace main.bin, make certain to manually update the entrypoint!
     The max size relies on several factors.  It must be entirely in the 1st zone and has to fit in memory either before or after the IPL's runtime.  Roughly speaking, it must end before 80260000 or after 80400000.
     On import, stub data is <boot number> LBAs.  There is no log of filenames or of any data beyond the start of this stub (except the LBA table within the stub itself at ~0x50, provided it's accurate).  Files WILL be missing on import.  If this is a concern, add the data to the ROM segment.
     The import table in the default stub isn't updated with the new import list.  They're just simple start/stop pairs for each block of data originally loaded.  They only apply to disk mastering and verification.
     On the flip side, it can be any kind of program.  You could write a file manager, slide show, video, a different game, or emulate the original Famicom Dezaemon.  It would be a hassle, but there's nothing saying you can't port Dezaemon 3D itself to pure disk.  It probably was to begin with...

-Zoinkity
